Authentication refers to the process that a recipient of an electronic message would follow to verify the integrity of the message as well as the identity of the sender. A digital signature is used in such authentication.
Conventionally, digital signatures are typically created and verified using public keys, and are used to identify authors or signers of electronic data. Digital signatures provide several features including (1) the ability to authenticate the identity of the signer of the data, (2) the ability to protect the integrity of the data, and (3) nonrepudiation which proves the identity of the parties that participated in the transaction.
There are various conventional techniques for verifying the authenticity of the signer and the integrity of the data. One may have to visit the web site of a third party certificate issuing authority and verify that the provided public key indeed belongs to the signer. The certificate issuing authority registers key owner credentials and therefore can verify whom the particular public key belongs to. Another technique to verify the signer identity is to compare the provided public encryption key to a trusted key already present in the computer. That trusted key could be obtained earlier by other means (e.g., delivered via ordinary mail, delivered as part of a separate encrypted email message, published in a newspaper, published on a secure web site, etc.).
As XML (extensible markup language) becomes a vital component of the emerging electronic business infrastructure, it is desirable to provide trustable, secure XML messages to form the basis of business transactions. The W3C (World Wide Web Consortium) has recommended applying digital signatures to XML.
One feature of XML digital signatures is the ability to sign only specific portions of the XML tree rather than the complete document. This is relevant when a single XML document may have a long history in which different components are authored at different times by different parties, each signing only those elements relevant to itself. This flexibility is also desirable in situations where it is important to ensure the integrity of certain portions of an XML document, while leaving open the possibility for other portions of the document to change. Consider, for example, a signed XML form delivered to a user for completion. If the signature were over the entire XML form, any change by the user to the default form values would invalidate the original signature.
An XML signature can sign more than one type of resource. For example, a single XML signature might cover character-encoded data (HTML), binary-encoded data (JPG), XML-encoded data, and a specific section of an XML file.
The components of a conventional XML signature are now described with respect to the exemplary elements shown below.
<Signature> <Signed Info>  (Canonicalization Method)  (Signature Method)  (<Reference (URI=)?>   (Transforms)?   (Digest Method)   (Digest Value)  </Reference>) </Signed Info> (Signature Value) (Key Info)? (Object)</Signature>
Each resource to be signed has its own <Reference> element, identified by an Uniform Resource Identifier (URI) attribute. The <Transform> element specifies an ordered list of processing steps that were applied to the referenced resource's content before it was digested. The <Digest Value> element carries the value of the digest of the referenced resource. The <Signature Value> element carries the value of the encrypted digest of the <Signed Info> element. The <Key Info> element indicates the key to be used to validate the signature. Possible forms for identification include certificates, key names, and key agreement algorithms and information.
To create a conventional XML signature, an initial step is to determine which resources are to be signed, by identifying the resources through a URI. For example, “http://www.abccompany.com/index.html” would reference an HTML page on the Web; “http://www.abccompany.com/logo.gif” would reference a GIF image on the Web; “http://www.abccompany.com/xml/po.xml” would reference an XML file on the Web; and “http://www.abccompany.com/xml/po.xml#sender1” would reference a specific element in an XML file on the Web.
Next, the digest of each resource is calculated. In XML signatures, each referenced resource is specified through a <Reference> element and its digest (calculated on the identified resource and not the <Reference> element itself) is placed in a <DigestValue> child element such as:
<Reference URI=“http://www.abccompany.com/news/2000/03_27_00.htm”> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig# sha1” /> <DigestValue>j61wx3rvEPO0vKtMup4NbeVu8nk=</DigestValue></Reference><Reference URI=“http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/ signature-example.xml”> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig# sha1”/> <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue></Reference>The <DigestMethod> element identifies the algorithm used to calculate the digest. A large number (i.e., the digest value) is then generated.
The reference elements are then collected (with their associated digests) within a <SignedInfo> element such as:
SignedInfo Id=“foobar”><CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n- 20010315”/><SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#dsa-sha1” /><Reference URI=“http://www.abccompany.com/news/2000/03_27_00.htm”> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig# sha1” /> <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue></Reference><Reference URI=“http://www.w3.org/TR/2000/WD-xmldsig-core-20000228/ signature-example.xml”> <DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig# sha1”/> <DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</ DigestValue> </Reference></SignedInfo>
The <CanonicalizationMethod> element indicates the algorithm that was used to canonize the <SignedInfo> element. Different data streams with the same XML information set may have different textual representations, e.g., differing as to whitespace. To help prevent inaccurate verification results, XML information sets are first be canonized before extracting their bit representation for signature processing. The <SignatureMethod> element identifies the algorithm used to produce the signature value.
The digest of the <SignedInfo> element is then calculated and that digest is signed and the signature value is put in a <SignatureValue> element, as shown below, for example.
<SignatureValue>MC0E LE=</SignatureValue>
If keying information is to be included, it is placed in a <KeyInfo> element. As shown below, the keying information contains the X.509 certificate for the sender, which would include the public key needed for signature verification.
<KeyInfo> <X509Data> <X509SubjectName>CN=EdSimon,O=XMLSec Inc., ST=OTTAWA, C=CA  </X509SubjectName> <X509Certificate>MIID5jCCA0+gA...1VN</X509Certificate> </X509Data></KeyInfo>   The <SignedInfo>, <SignatureValue>, and <KeyInfo>   elements are placed into a<Signature> element, shown below. The <Signature> elementcomprises the XML signature.<?xml version=“1.0” encoding=“UTF-8”?><Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”><SignedInfo Id=“foobar”><CanonicalizationMethod Algorithm=“http://www.w3.org/TR/2001/REC-xml-c14n- 20010315”/><SignatureMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#dsa-sha1” /><Reference URI=“http://www.abccompany.com/news/2000/03_27_00.htm”><DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1” /><DigestValue>j61wx3rvEPO0vKtMup4NbeVu8nk=</DigestValue></Reference><Reference URI=“http://www.w3.org/TR/2000/WD-xmldsig-core- 20000228/signature-example.xml”><DigestMethod Algorithm=“http://www.w3.org/2000/09/xmldsig#sha1”/><DigestValue>UrXLDLBIta6skoV5/A8Q38GEw44=</DigestValue></Reference></SignedInfo><SignatureValue>MC0E~LE=</SignatureValue><KeyInfo><X509Data><X509SubjectName>CN=Ed Simon,O=XMLSec Inc.,ST=OTTAWA,C=CA   </X509SubjectName><X509Certificate>MIID5jCCA0+gA...lVN</X509Certificate></X509Data></KeyInfo></Signature>
The XML digital signature is an XML fragment with specified schema, which includes (a) data to describe how the signature should be calculated (e.g., digest methods, filters, data sources, etc.) and (b) actual signature data (e.g., digests and signature value). A conventional XML digital signature implementation requires a program to specify the “group (a)” data through program calls, and then generates a signature element with both the “group (a)” and “group (b)” data. Such an implementation is computation extensive, thereby requiring a lot of valuable processor resources and time.
In view of the foregoing, there is a need for systems and methods that overcome the limitations and drawbacks of the prior art.